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Description 

[0001] This invention relates to telecommunication 
networks operating internet Protocol (IP), and relates 
especially to a method of reserving resources. 
[0002] In third generation (3G) telecommunications 
networks, such as Universal Mobile Telecommunication 
Systems (UMTS), broad bandwidth is provided for serv- 
ices such as data and multimedia in addition to voice. 
An obvious need is that required Quality of Service 
(QoS) should be provided to users but in IP networks if 
contention for resources is not resolved then QoS can 
not be guaranteed. 

[0003] In IP networks or, in general, Internet, Re- 
source Reservation Protocol (RSVP) is used to allow the 
network to reserve the resources so as to provide QoS. 
RSVP is an end-to-end protocol and is illustrated in Fig- 
ure 1. 

[0004] A transmitting user 1 0 sends to a receiving us- 
er 1 2 a message PATH. The PATH message carries the 
traffic characteristics information such as TSpecs to in- 
dicate the traffic behavior that is to be sent from the user 
10. 

[0005] When the receiving user 1 2 receives the PATH 
message, it sends a RESV message that contains QoS 
request such as FlowSpecs. 

[0006] In practice, the transmitting and receiving us- 
ers 1 0 and 1 2 can be located remotely so that PATH and 
RESV messages pass through several nodes. As each 
node receives both messages, it makes the decision as 
to whether adequate resources in that node can be re- 
served. If this is possible, then the messages are re- 
layed to the next hop for the PATH message and the 
previous hop for the RESV message. When the RESV 
message reaches the transmitting user 1 0, it begins to 
transmit data. 

[0007] Periodic refresh messages are sent subse- 
quently to maintain the QoS status at each node that 
has been set up. 

[0008] In UMTS, RSVP may be used to support those 
applications that use RSVP to activate the QoS control. 
It is proposed in TSG2#10 S2-0000131, "Processing 
RSVP Signalling in MP' that RSVP is supported in MT 
for activating QoS control in UMTS. But the major draw- 
backs that have been envisaged are that the RSVP 
messages are transmitted separately across the UMTS 
networks and thus consume extra UMTS network re- 
sources, in particular, the radio resources. In addition, 
it increases traffic load to the UMTS network. 
[0009] It is an object of the invention to provide a 
method of reserving resources in third or future gener- 
ations of wireless mobile networks such as UMTS net- 
works that has no or minimal impact on existing archi- 
tecture or QoS procedures, and minimizes any extra sig- 
nalling traffic associated with supporting the method. 
[0010] According to the invention, in a third or future 
generation telecommunication network, a method of al- 
locating resources for user traffic passing between a 



2 

mobile terminal and a remote user characterized by 
sending at least a data object content of a quality of serv- 
ice request transparently between a support node as- 
sociated with said remote user and said mobile terminal. 
5 [0011] In the accompanying drawings, Figure 1 illus- 
trates the operation of RSVP. The invention will be de- 
scribed by way of example only with reference to Figure 
s2 and 3 in which:- 

10 Figure 2 illustrates the schematically the UMST;and 
Figure 3 illustrates the interchange of messages ac- 
cording to the invention. 

[0012] In Figure 2 the UMTS 20 comprises a Core 
15 Network (CN) 22 formed by Gateway 24 and aCN Edge 
26 and a UMTS Terrestrial Radio Access Network 
(UTRAN) 28. A Mobile Terminal (MT) 30 communicates 
with the UTRAN 28 across the radio interface. The MT 
30 is UMTS specific and is connected to the Terminal 
20 Equipment (TE) 32 that may run non-UMTS specific ap- 
plications. 

[001 3] The Gateway 24 can communicate with Exter- 
nal Network 40. 

[0014] Each illustrated component has sub-compo- 
25 nents which are not further described. 

[0015] The UMTS 20 operates the Application-specif- 
ic Packet Data Protocol (PDP) Context as usual to ne- 
gotiate the QoS and activate the QoS control between 
the MT 30 and UMTS network 20. 
30 [0016] In Figure 3, the CN Edge is now termed Serv- 
ing GPRS Support Node (SGSN) 26 and the Gateway 
is now termed Gateway GPRS Support Node (GGSN) 
24. 

[0017] In the inventive method, the RSVP messages 
35 are "piggybacked" to the PDP Context messages. Fig- 
ure 3 illustrates RSVP activated QoS control in the up- 
link direction. 

[0018] The RSVP session is used end-to-end and ter- 
minated at the MT 30 and the GGSN 24. The assump- 
40 tion is that the TE 32 intends to set up RSVP session 
with its remote peer (not shown) that also uses RSVP 
signaling in the external network. 
[0019] When the MT 30 receives the PATH message 
fromTE 32, MT 30 checks to see if a PDP context exists 
45 for this RSVP session. If it does, the MT triggers the 
Modify/Create Secondary PDP context message if there 
is a change in QoS parameters or if a secondary PDP 
context needs to be created. The PATH message is pig- 
gybacked on the Activate/Modify PDP context Request 
50 messages using the PDP config. option. Note that the 
MT is expected to populate the Requested QoS IE 
based on the PATH information. SGSN 26 can use the 
information within the Requested QoS IE (Information 
Element) to do RAB negotiation with UTRAN 28. The 
55 PATH message will be relayed to GGSN 24. The GGSN 
extracts the PATH message and then relays it to the ex- 
ternal network. 

[0020] The GGSN can generate the PDP context re- 
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sponse without waiting for the RESV message. Howev- 
er, with that approach, GGSN may not be able to popu- 
late the Negotiated QoS IE with values that matches 
RESV QoS requirements. Figure 3 shows that the 
GGSN waits for RESV before generating the PDP con- 
text response message. 

[0021] When the RESV response from the remote 
peer is received at the GGSN 24, it uses this information , 
along with relevant local configuration, to see if QoS Ne- 
gotiated is the same as QoS Requested. Then it piggy- 
backs the RESV message on the Activate/Modify PDP 
Context response message using the PDP config. op- 
tion. RAB re-negotiation can take place between SGSN 
and UTRAN if QoS Negotiated is different from QoS Re- 
quested. Finally the RESV message possibly adapted 
at the GGSN is sent on to the TE 32 by piggybacking 
on the Activate /Modify -PDP Context Confirmation 
message(s). 

[0022] It is an advantage of this arrangement that 
RSVP refresh messages are not required, becauses a 
PDP operates a specific release process. 
[0023] This proposed piggybacking of RSVP messag- 
es/Traffic &QoS Data Objects on PDP Context control 
messages aims to speed up the end-to-end QoS nego- 
tiation process and minimizes the extra traffic load on 
the network, in particular, over the air interface. 
[0024] An alternative solution is to extract the Traffic 
and QoS Data Objects such as the Tspec, ADSpec from 
the PATH message and the FlowSpecs from the RESV 
message and piggyback them using the PDPconfig. op- 
tion to the Activate/Modify PDP Context Request/Re- 
sponse messages. 

[0025] In these circumstances the GGSN can deter- 
mine if it is a PATH message or a RESV messages or 
other RSVP messages carried by secondary PDP con- 
text by looking for the header information. A special flag 
is provided on QoS data objects. There are at most 
twelve such objects, so a flag occupies at most half a 
byte; a single byte can accommodate ail the diffeent 
types of RSVP messages indudingthe PATH and RESV 
messages. 



3. A method according to claim 1 or 2 in which the 
quality of service request is carried in the resource 
reservation protocol. 

5 4. A method according to any preceding claim in which 
the data objects are each identified by a header in- 
formation. 

5. A method according to any preceding claim com- 
10 prising sending an entire quality of service request. 



20 



25 



30 



35 



Claims 

45 

1. In a third or future generation telecommunication 
network, a method of allocating resources for user 
traffic passing between a mobile terminal and a re- 
mote user characterized by sending at least a data 
object content of a quality of service request trans- 50 
parently between a support node associated with 
said remote user and said mobile terminal. 

2. A method according to claim 1 in which the telecom- 
munication network operates a packet data protocol 55 
context and the data object content is included in a 
packet data protocol context message. 
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